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(54) Method and apparatus for telecommunications using internet protocol 



(57) In a wireless packet switching telecommunica- 
tions network, voice services are provided by having a 
compressor/decompressor (64) in each mobile station 

(60) to provide each voice packet with a compressed 
header. Voice data and signalling data are sent sepa- 
rately and in different data formats to the air interface 

(61) . The compressed header may be an M bit and a 
cyclically reset timeclick_n umber, which is decom- 
pressed by use of a waltclock which counts reset cycles 



to reinstate the voice packet headers. Alternatively, RTP 
agents are provided at the compression and decom- 
pression points, and voice packets are sent without 
headers over a "high quality" network such as a frame 
relay or ATM network. Compression state of a voice 
packet header can be established by sending call set-up 
information over an out-of-band channel between com- 
pression points in a mobile station and in the network. 
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Description 
Abbreviations 

5 [0001] The following abbreviations are frequently used in the draft: 

PSTN: Public Switched Telephone Network 

TCP: Transport Control Protocol 

UDP: User Datagram Protocol 
w RTP: Real Time Protocol 

IP: Internet Protocol 

VoIP: Voice Over IP 

CD: compressor/de-compressor 

-CDMA: Code Division-Multiplexing Access - - — - 

rs MAC: Medium Access Control 

RLC: Radio Link Control 

GSM: Global System for Mobile communication 

GPRS: General Packet Radio Service 

20 1 . Field of the Invention 

[0002] This invention relates to an apparatus and method for telecommunications using Internet Protocol, and 
relates especially to an advantageous data compression arrangement. 

[0003] In a wireless telecommunications network operating a packet switching technology, it would advantageous 
25 to be able to offer voice and data services using the Internet, but the need to transmit the combined headers of Real- 
time Transport Protocol (RTP), User Datagram Protocol (UDP) and Internet Protocol (IP) in each packet header is a dis- 
advantage. The three headers are respectively 20, 8 and 1 2 bytes per packet, and this 40 byte load is nearly double the 
voice payload of 23 bytes for 20 milliseconds in the voice coding system known as GSM FR. It is well known that wire- 
less resource/bandwidth is more expensive than landline arrangements, and the overload of the large header load is a 
30 serious drawback. 

2. Brief Description of the Prior Art 

[0004] One solution as disclosed by S Casner and V Jacobson, "Compressing IP/UDP/RTP Headers for Low- 
35 Speed Serial Links", RFC2508, ftp^/ftp.isi.edu/in-notes/rfc2508.txt is to compress the RTP/UDP/IP headers. A protocol 
is defined to compress and decompress the headers, and a reduction to between 2 and 5 bytes can be achieved. How- 
ever, a major disadvantage is that if a compressed packet is lost it must be re-transmitted and the provision of an error- 
recovery facility is essential, and therefore the round-trip-time must be short if quality is to be maintained. Further, for 
many radio networks in which the radio bearer capacity is designed for circuit voice service so the link layer PDU size 
40 is designed to match voice payload, it is difficult to put even 2-5 more bytes into one Medium Access Control (MAC) 
block, so that one voice frame with its compressed header may have to be transmitted in two MAC blocks, requiring 
extra radio resource or there may be loss of voice quality; yet again, handover may change the compression/decom- 
pression point in the network, requiring the compression state to be re-established, which needs a CONTEXT.STATE 
message then a FULL_HEADER packet to be sent, which causes delay and packet loss. 
45 [0005] In S Petrack, Ed Ellesson, Framedwork for Compressed RTP, Preliminary IETF draft, presented on rem-con 
mailing list. Feb 1996, httpV/www.mbone.com/iists/rem-conf.1996Q1/0259.html, it is suggested that the two time 
related fields (RTP sequence number and timestamp) can be compressed using a 1 -byte "timeclick" number and a sep- 
arate RTP session control is suggested to signal the static parts of the headers out of band, but no details are given of 
how to achieve this. 

50 

3. Summary of the Invention 

[0006] According to the invention, a mobile station for a packet switching radio network which includes a Voice over 
Internet Protocol application layer and Internet Protocol Stacks including Real Time Protocol, Transport Control Proto- 
55 col, User Datagram Protocol and Internet Protocol layers, further comprising a compressor/decompressor to compress 
voice data, and means to send voice data and call signalling data separately and in different data formats to the link 
layer and the air interface of the mobile station. 

[0007] In one arrangement the compressor/decompressor is arranged between link layer (which is above the phys- 
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ical layer in the air interface) and the IP layer, and receives both the voice data and the call signalling data. 

[0008] In an alternative arrangement the compressor/decompressor is arranged between the air interface and the 

VoIP applications layer, and receives the voice data 

[0009] Also according to the invention a packet switching radio network comprising a plurality of mobile stations as 
defined above and at least one network element in which there is compressor/decompressor means arranged to 
receive signals relating to compressed voice data. 

[0010] Further according to the invention a method of operating a packet switching radio network to provide voice 
services comprising separating the voice data from the call signalling and other data, whereby each voice packet con- 
taining voice data can be provided with compressed or removed RTP/UDP/IP headers. 

[0011] Yet further according to the invention, a first method of compressing and decompressing headers for a 
packet switching network comprises providing in each compressed header a cyclically-reset timeclick_n umber repre- 
senting the sampling time of the packet payload; increasing the timeclick_number by 1 for each sample duration time, 
counting the reset cycles, and from the count of reset cycles and a received timed ick_number, providing a sequence 
number and timestamp for providing a decompressed header. 

[0012] Yet further according to the invention, a second method of compressing and decompressing headers for a 
packet switching network comprises removing combined RTP/UDP/IP headers and placing data in RLC/MAC payload; 
and decompressing received packets by use of an internal clock to obtain a timestamp value, and increasing the 
sequence number by 1 for consecutive packets. 

[0013] Also according to the invention, a method of establishing a compression state of a packet header in a packet 
switching network by making use of call set-up information over an out-of-band protocol. 

4. Brief Description of the Drawings 

[0014] The invention will now be described by way of example with reference to the accompanying drawings in 
which: 

Figure 1 illustrates a wireless packet switching network based on the UMTS model. 

Figures 2a and 2b shows two embodiments of the invention in a mobile transceiver; 

Figure 3 illustrates an entire communication channel; 

Figures 4a and 4b illustrate alternative compression algorithms; 

Figure 5 shows establishment or re-establishment of compression state; and 

Figure 6 shows inter-compression point handover. 

5. Description of a Preferred Embodiment of a Mobile Station and Network 

[0015] In Figure 1 , a wireless mobile telecommunication system 10 comprises a number of Mobile Stations (MS) 
12 and a number of base transceiver stations (Node B) 14 connected through a RNC (Radio Network Controller) 16 (all 
in the Radio Access Network RAN 1 8) to a packet Core Network (CN) 20 which consists of two elements: a SGSN 
(Serving GPRS Support Node) 22 and a GGSN (Gateway GPRS Support Node) 24. The CN is connected via a 
IP/PSTN Gateway 26, to the PSTN (Public Switched Telephone Network) 30 and to the Internet 28. 
[0016] In this Figure the network architecture is based on the UMTS reference model. 

[0017] Suppose the network 10 operates in packet switch mode. One way to implement voice service is to use VoIP 
technology in which VoIP application from the mobile station 12 is treated as a general IP application and coded voice 
is decomposed into RTP/UDP/IP packets and transmitted over the air, the RAN 1 8 and the CN 20 to Internet 28 or the 
PSTN 30 via the IP/PSTN gateway 26. 

[0018] At a mobile station 12, IP-based call signalling and the Graphical User Interface of VoIP application can run 
in the same way as on a normal IP terminal. The voice traffic is sent as a link layer payload with compressed or removed 
RTP/UDP/IP header information, as will be explained in more detail below. 

[0019] Referring to Figure 2a, the up-link direction is considered from a mobile station 60 to the network. In the 
mobile station there is a VoIP application layer 68 from which call signalling data is sent to a TCP layer 66 and a UDP/IP 
layer 65. Voice data is transmitted to an RTP/UDP layer 67 and an IP layer 65. 

[0020] Both call signalling data and voice data in packets are provided to a compressor 64, which compresses the 
combined RTP/UDP/IP headers, but the compressor does not compress the call signalling data. The two types of 
packet 62,63, (compressed and uncompressed) are put in RLC/MAC protocol, and pass over the air interface 61. 
[0021] To receive voice and call signalling data (the downlink direction) the process is reversed. 
[0022] In the alternative arrangement for a mobile 70 shown in Figure 3b ( the compressor 74 sends/receives the 
voice data 63 to/from VoIP application 78 while call signalling data 62 passes through normal IP layers 75, 76. 
[0023] It can be seen that in both arrangements the voice and call signalling data are separated. 



[0024] Figure 3 illustrates a whole system, in which a mobile 60 with its compressor 64 is connected through the 
air interface 61 sequentially to a Radio Access Network (RAN) 81 which tunnels or relays data between the air interface 
61 and the Core Network 84, and a decompressor CD 83 in CN 82 connected to any IP host 85 via the Internet 
[0025] In the arrangements shown in Figures 2a, 2b and 3, it is assumed that the IP/UDP/RTP header information 
5 is not used for routing etc, from the mobile station 60 to the CD 83 in CN 84; instead all data including voice packets are 
relayed/tunnelled. It is assumed that the packets are delivered in sequence between the mobile 60 and the CD 83. It is 
further assumed that some mechanism will be able to distinguish compressed (speech) packets from normal (uncom- 
pressed) packets, and this distinction can be maintained until CN 84 is reached. 

[0026] The arrangement described may achieve a level of radio efficiency which is of a similar level to a circuit 
10 switched voice service provided by wireless telecommunications systems such as GSM. 

[0027] It is a further advantage that no error recovery mechanism is needed, and there is no inter-packet depend- 
ency for decompression, so packet loss does not cause malfunction of the compression point 
[0028] The VoIP applications 68, 78 run as if they are accessing a normal IP network although the voice packets 
are treated differently along part of their journey — from the MS 60 to CN 84. Also, from the viewpoint of the other IP 
is endpoint 85 (a user terminal or a IP/PSTN gateway), the elements in the RAN 81 (MS 60, Node B and RNC 80) are 
treated as a set as a endpoint, because the voice frames (data 63) need to travel a relatively long way before being 
RTP-framed at CD 83. 

[0029] General benefits of the arrangement are that there is higher compression gain and saving of resources; that 
the system operates when the round-trip-time between compression and decompression is long; and that the benefits 
20 from IP-based call signalling can be kept 

6. Description of Two Preferred Algorithms 

[0030] There are two compression algorithms for IP/UDP/RTP headers, one can be characterized as a "best-effort 
25 lossy compression" and another one can be characterized as "Zero header compression". Both algorithms are based 
on the fact that the IP/UDP/RTP headers are not used between MS 64 and CN 84. 

6a. First Preferred Algorithm 

30 [0031] The objective is to break up the interdependency of the compressed packets. Instead of sending relative val- 
ues in the compressed headers (by differential coding), absolute values (timeclick numbers) are sent as suggested by 
Petrack. As there is no inter-relationship between compressed RTP packets, packet loss will not stop decompression 
from operating. 

3$ - Using the first algorithm the compressed header can be only 1 byte, in comparison with 2 to 5 bytes in a known 
arrangement The most important information in RTP header, the two time related fields — timestamp and 
sequence number, need to be retained. As pointed out in the paper by Petrack referred to above, these two fields 
can be replaced by a "timeclick number" (in one byte). This number assists the decompressor to put a proper times- 
tamp (reflecting the sampling time at the mobile station 60) and sequence number. The publication suggests that 

40 instead of the conventional timestamp and RTP number, a single 1 byte timeclick" number is sent with each 
packet However, in the prior publication there was no disclosure of how to recover the timestamp and sequence 
number or how to establish compression states out of band. 

It is assumed that there is only one VoIP session requiring compression per terminal, thus no CID (Context ID) bits 
45 is required. The M bit in RTP header is kept and transmitted with each compressed packet. 

[0032] Compression-state, first algorithm. The compression state contains the following information for a call 
(consisting of two RTP sessions) to be compressed: for each call-end: IP address, two port numbers (sourcing and 
incoming), SSRC etc. for the call: the codec used and its parameter (e.g. sampling rate and sample duration). The 
so codec for both directions is assumed to be the same. (If not then need to store them separately). 

[0033] The establishment of the compression-state is via an out-of-band protocol, which can work together with the 
call signalling protocol, and wiil be described later. This protocol will also help to migrate the state information from one 
CD to another one in the case of handover between CDs. 

[0034] Compression process, first algorithm. Through the compression, three fields will be preserved in a nearly 
55 lossless way: timestamp, sequence number and the M bit A byte (8 bits) is used for the compressed header: the first 
bit is used for the M bit, and the other 7 bits for timeclick, number, which represents the sampling time of the voice pay- 
load contained in the packet It is increased by 1 every sample duration time, e.g. 20 ms for GSM6.1 0 coding. It will con- 
tinue to be increased even in the silent period when no packets are actually sent out 
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[0035] The fields whose information may become inaccurate through the compression are: 

The packet ID in IP v4. It is assumed that the packet ID field always increases by 1 so it does not need to be com- 
municated . When packet loss is detected the ID value is set accordingly. As not all packet-loss can be detected so 
5 the ID value may become inaccurate. 

UDP checksum field. The checksum field is not used (set to 0) from mobile terminal 60. If it is used on the down- 
link direction, it is set to 0 by the CD in the network (and then the end-to-end error detection for applications that 
require it is disabled). Thus the error correction using the UDP checksum will be disabled. 

10 

RTP CSRC list. For the uplink direction, the CSRC list should always be empty. For the downlink direction, it may 
change (e.g. in the case of conference call). For 2-party call, it wiil be unchanged (empty). 

- Sequence number. In the case of packet loss between the mobile station and the RTP proxy, and the decompressor 
is failed to detect it, the sequence number recovered by the RTP proxy is incorrect, which may influence the accuracy 
of the statistical result of packet loss rate. 

[0036] There are two modes of accessing the compression service. One is accessed by the VoIP application 
directly (as shown in Figure 3(b)), by-passing the transport and network layers. The obvious benefit is the efficiency, but 
20 it may need some change of the application or need a transport layer wrap up. The service access primitive for the com- 
pressor can be: 

compress (M, timeclick_number, voicepayload) 

25 [0037] It is straightforward to generate a compressed RTP packet with these three data items. 

[0038] Alternatively the compression service can be accessed by the network layer in a transparent way (as shown 
in Figure 2(a)), thus all upper layers are unknown about the compression. In this case, upon receiving a packet from 
upper layer, it checks the fields of source/destination IP and port number also the source SSRC. These five fields will 
identify a RTP session and by checking these field against the compression-state table, it is decide either to compress 

30 the packet (if it is a RTP packet whose compression state already established), or treat it like non-RTP, normal packet. 
If it is a RTTP packet to be compressed, the timestamp field is mapped to a timeclick-number. Then the above service 
primitive can be called. 

[0039] For the downlink direction, if the UDP checksum is used (non-zero), it will be ignored. 
[0040] After a compressed RTP packet is generated, it is put in a link layer packet together with a marker telling it 
35 is a speech packet Other non-compressed packet will be put into a link layer packet marking itself as general data 
packet 

Decompression process, the first algorithm. 

40 [0041] Except for the time-related RTP header fields, recovery of the other fields are from the compression state 
using a similar approach to RFC 2508. 

[0042] For the timestamp field: the major problem to solve is that the field for timeclick number is only 7 bits. The 
click counting will continue and can easily wrap around (reset periodically) during a single telephone call). During a 
silent period, if there is no packet sent by the compressor, the time elapsed for this silent period (in terms of how many 
45 cycles passed), must be detected. 

[0043] In the first algorithm according to the invention, a computer clock at the CD 84 is used to count the cycles 
and the timeclick number is used, with reference to the clock reading, to set the timestamp field. The dock can run at a 
coarser granularity. For example it can be increased by 1 for every T/4 period assuming the maximum jitter is less than 
T/4, which is a safe assumption, where T is the time period of a cycle represented by 7 bits. It is usually several see- 
so onds, depending on the codec parameters. 

[0044] Turning now to the sequence number, this number is normally increased by 1 for each consecutive packet. 
It is mainly used to reflect the packet loss. In the first algorithm according to the invention, a heuristic method is used to 
detect packet loss by checking both the increases of timeclick number and the M bit If the timeclick number is increased 
by a small number other than one (say two, three etc.) but the M bit is not set, then there is likely some packet-loss. In 
55 this case the sequence number is increased by the difference of the timeclick number. In the case of the packet that 
carries the set M bit gets lost (then the bigger increase of timeclick number is normal, as it is silent period), the 
sequence number should still be increased by 1 . The probability for this situation to happen is quite small. Even if this 
happens and the sequence number is increased by mistake, it will slightly influence the statistic result of packet-loss 
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rate perceived by the other RTP end (a few more packets are reported to be lost). 

Denotation: 

[0045] 

sd: sample duration, the value should come from the call setup procedure, e.g. 20ms (voice in each packet) 

sr: sample rate, the value should come from the call setup procedure, e.g. 8000 

nb: number of bits used for the timeclick number 

TStast Timestamp number for the previous packet 

TSthis: Timestamp number for this packet 

VfTlast: Wallclock reading for the previous packet 

VfTthis: Wallclock reading for this packet 

THIast: Timeclick number of previous packet in compressed header 
THthis: Timeclick number of this packet in compressed header 
SHIast: RTP sequence number of previous packet 
SNtfwsL: RTP sequence number of this packet 

T: the time period represented using nb bits (a cycle period), in units of sample duration (sd) 

T = 2**nb 

M: the value of the "M" bit, in compressed header 
[0046] Calculating the timestamp and sequence number: 

TSthis = Tslost + l , if M = 0 and delta Jick = 1 

= Tslast + (deita_cycle*(2**nb) + delta Jick)*sd*sr/1 000, 
otherwise where: 

delta Jick = (T + Tnthis - Tnlast) mod T 
delta^wtick = Wtthis-Wtlast mod T 
delta_cycle = (Wtthis-Wtlast)/T/*integer part*/ 

delta_cycle = delta_cycle' -1, if delta wtick < delta tick and delta tick- 
delta wtick >= T/2 

delta_cycle* +1, if delta Jick < delta_wtick and deita_wtick- 

delta Jick>= T/2 
= delta jycle\ otherwise 
Snthis = Snlast + delta Jick, if delta Jick !=1 and delta Jick < 4 and M !=1 



6b. Second Preferred Algorithm 

[0047] The second algorithm for header compression is now described; the header may be zero. 
[0048] In some cases, for example, GPRS (General Packet Radio System, an overlay packet network over GSM 
system), the radio bearer channel is designed in such a way that it is hard to put any extra header information together 
with speech data. Thus we would like to investigate if it is possible to transmit voice in "raw" format (speech only), but 
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still keep most of the benefits from IP telephony (e.g. IP based call signalling thus enable CPL, web-based call etc). 
[0049] The basic idea of this solution, as shown in Figure 4b, is that considering that the path between mobile sta- 
tion 60 and CN 84 is over a controlled packet network (over frame relay or ATM, for example) and certain QoS will be 
provided (no mis-ordering, the jitter and packet-loss-rate are small so that the voice quality will not suffer on this path), 
it is possible completely to remove the IP/UDP/RTP headers between mobile station and CP and use a box called RTP 
agent as the decompressor in CN. 

In this case the RTP agent (up line direction) performs a role similar to the IP/PSTN gateway: for the up link direc- 
tion, the voice frames from a mobile station are transmitted without any IP/UDP/RTP headers, in a way very dose 
to the circuit-mode voice in wireless networks, e.g. in GSM, (but is over a "good" quality packet network), up to the 
RTP agent which adds proper headers and sends them off to VoIP networks. On the downlink direction, the RTP 
agent strip off the headers and transmit them up to the mobile station. 

[0050] Using the second algorithm, the benefit of IP based call signalling and service creation is retained. At the 
same time there is the benefit of high radio resource efficiency. On the other hand, the mobile terminal may lose some 
capability relying on RTP header information; for example to find the packet-loss-rate and packet delay, and the play 
buffer may be adjusted accordingly. 

[0051] The major differences between the first and second algorithms are that, when using the second algorithm: 

On the mobile station, the VoIP application loses the chance of using any time-related information in RTP header. 
For example to detect the packet-loss and calculate the jitter. Note that the compression itself will not introduce 
extra packet-loss and jitter. It would be difficult to generate proper RTCP packets but can ask RTP agent to do this 
job on its behalf. 

From the viewpoint of the other IP endpoint of the call (a user terminal or gateway), the packet loss detected by the 
RTP agent (and reflected in the fields of sequence number and timestamp) may be less accurate than the first algo- 
rithm. 

[0052] The way that the CD in the second algorithm adds on (up link) and strips off (down link) IP/UDP/RTP head- 
ers is similar to that used in a general IP/PSTN media gateway. The differences are: 

The general media gateway normally has two network interfaces: one for PSTN and another one for packet network 
(e.g. IP, ATM). It translates media between circuit-mode and packet-mode. RTP-agent has two network interfaces 
both of which are for packet network. 

In general media gateway, the voice coming from the PSTN side is continuous and its rate is constant. In our case, 
as voice frames are transmitted over packet network on both sides, it needs to do more; to try to detect the packet 
loss in order to put on correct sequence numbers and timestamps by examining the inter-arrival time of the packets 
from RAN side; it may need to send RTCP packets on behalf of the mobile terminal. 

[0053] Compression-state, second algorithm. This is the same as in the RTP-proxy approach. 

[0054] Compression process, second algorithm. The compression process is very simple: it just strips off any 

header and puts the speech data only into RLC/MAC messages. The service access primitive for the compressor can 

be: 

compress (voicepayload) 

[0055] Like in RTP-proxy approach, the compression service, at the terminal, can be accessed by the network layer 
in a transparent way. In this case, upon receiving a packet from the network layer, it checks the fields of source/dest IP 
and pot number, also the source SSRC. These five fields will identify a RTP session and by checking these fields 
against the compression-state table, it is decided either to compress the packet (if it is a RTP packet whose compres- 
sion state already established), or treat it like non-RTP, normal packet If it is a RTP packet to be compressed, the head- 
ers are strip off and the above service primitive can be called. 

[0056] For the downlink direction, the CD in the network checks each packet to see if it belongs to a RTP session 
being compressed. If yes the RTP/UDP/iP headers are stripped off and the speech data is put into the payload of, for 
example, the tunnelling protocol addressed to the right mobile terminal. 

[0057] Decompression process, second algorithm. At the decompressor in the network (CD 84), a computer 
clock is used. As for the first algorithm, the major problem is how to recover the time-related fields. There are two ways 
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to do this:- 
(a) 

5 - The decompressor checks at the beginning of every sampling duration period (the period covered by the 

speech frame(s) carried by an RTP packet; for example it will be 20ms if each FTP packet carries one 
GSM6.10 speech frame) to see if there is any compressed speech packet coming from RAN. If m yes" the 
decompressor adds IP/UDP/RTP headers on the packet The decompressor maintains a small buffer for 
incoming speech packets from RAN to smooth out the jitter. 

w 

The decompressor obtains the timestamp value from the internal clock (translated to the sampling time format 
as used in RTP). The sequence number is increased by 1 for each packet. 

- (b) 

75 

Alternatively, the decompressor checks the inter-arrival time of each compressed packet arriving at the RAN 
side to guess if there is any packet-loss, considering the variation of delay and the possibility of silent period. 
After this analysis is performed, if the packet just arrived is thought as the consecutive speech packet of the 
previous one, then timestamp is increased in the same way as at the source (added by a constant value, which 
20 is determined by the coding scheme used, on the top of the timestamp value of the previous one). The 

sequence number is added by one on the top of the sequence number of the previous packet If a packet loss 
is inferred then the sequence number and timestamp will be increased accordingly to reflect the gap. If a long 
gap is detected and a silent period is inferred, the sequence number is added by 1 but the timestamp need to 
reflect the gap. 

25 

[0058] While the first and second preferred algorithms have been described with reference to a packet switching 
radio network, both algorithms may also be applied in other circumstances where the following features hold: 

- The first leg between a mobile station and IP network is a point-to-point like connection over which the IP headers 
30 are not used. 

- The first leg of connection guarantee in-order delivery and small jitter. Some header inaccuracy pointed out before 
is acceptable for the application. 

35 7a. A preferred process of compress-state establishment and re-establishment 

[0059] The compression-state establishment process is used for several purposes/occasions: 

- At the beginning of a RTP session, the compression-state needs to be established to start compression and 
40 decom presst on . 

- When inter CDs handover happens, the compression-state needs to be migrated to the new CD from mobile termi- 
nal and/or from the old CD. 

45 [0060] The compression-state contains the following information: IP address and SSRC for both call ends, two 
pairs of RTP (UDP) port numbers, payload type, sampling rate, sample duration, etc. 

[0061] It is assumed that the voice coding for both directions are the same, otherwise they need to be stored sep- 
arately. 

[0062] The compression state establishment and re-establishment are done using an out-of band protocol, which 
so is shown in Figure 5, which shows a mobile station compressor 90 connected to a VoIP call control layer 92 under third 
party control; a serving network CD 94 and another network compressor 96; and the network CDs 94, 96 are connected 
directly by an out-of-band link 98, and are also connected to a VoIP call control layer 100 and a mobility management 
layer 102 under third party control. 

[0063] All the CDs 90, 94, 96 are in reality compressor/decompressors. 
55 [0064] The CDs 90 at the mobile station and 94 in the network have a control interface. Both CDs listen on a known 
port to accept instructions to start/stop compression and receive state information from the third party. Typically the 
instruction and information come from the voice application at MS and/or signalling gateway (e.g. a 4.323 Gatekeeper 
or SIP (Session Initiation Protocol) server) inside network. (Assume that the IP address of the sewing CD is known to 
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the signalling gateway.) 

[0065] There are six messages defined between CD and a third party control or between two CDs (not including 
the acknowledgement messages): 

1. STATE_START. This message indicates that a new compression session and its state is to be established. It 
should contain an identity of the MS being involved in the session. As an option it can contain a full (uncompressed) 
RTP packet so that the compression state information can be extracted from it 

2. STATEJNPUT. This message provides or modifies values of state attributes. It contains a list of (attribute_name, 
value) pair. 

3. STATE_ENQRY and STATE_ENQRY_RPL. These two messages can be used to inquiry the state information 
and to know if it is ready to perform compression/decompression tasks. 

4. STATE_HANDOVER. This message informs a current serving CP to send state information to a new CP, or asks 
a new serving CP to acquire state information from a previous serving CP. The message contains information bout 
the IP address of old and new CPs and the identity of the MS involved. 

5. STATE_STOP. This message deletes a compression state. A compression can also be deleted by compressor 
itself when necessary. 

[0066] The message STATEJNPUT is also used between the compressor 90 at MS and the CD 94, 96 in network 
to exchange state information. So the information available at one end will be available at the other end by using this 
protocol. 

[0067] The messages STATEJNPUT and STATE_ENQRY are also used for moving state information from one CD 
to another in the case of handover. Apart from the state elements listed above, some extra information such as local 
clock reading is also exchanged to the new CD. 

[0068] It is allowed for the compressor to pick up values or use default values for some attributes in some circum- 
stances. 

[0069] This process also supports the state re-establishment between CDs at MS and in network. This is necessary 
when the state information is damaged or lost at one side. Once the compressor at CD or MS detects the miss or incom- 
pleteness of state information, it can use STATE_ENQRY to obtain the state information from the other end. 
[0070] While the inventive process of establishing or re-establishing compression state has been described with 
reference to a packet switching radio telecommunications network, the process may also be used for any compression 
process for a connection oriented application such as VoIP and multimedia sessions. 

8. Two preferred processes for handover between two compression-points 

[0071] One problem to use the compression scheme presented in RFC2508 within wireless networks is the impact 
of mobility. When a handover occurs, it is possible that the serving CD will change. So the compression states stored 
in the CD before handover have to be moved to or re-established at the new CD. 
[0072] Two alternative approaches are proposed to cope with this problem: 

• Firstly, we can arrange some communication between two CDs so that they can exchange compression states, as 
shown in Figure 6 in which a mobile station having a compressor 104 is handed over from a serving CD in network 
106 to a new CD 108 in network. The serving and new CDs 106, 108 are provided with an out-of-band communi- 
cation channel 110. 

One way is to share the compression state information among a group of CDs (which may potentially become 
the serving CD after handover), so that when handover happens the necessary compression context already 
ready in the new CD. The cost of this method is the CPU time and memory required to receive/store the context 
which may not be used at all. 

Another way is to exchange the contact information during handover. To apply this approach, we need the co- 
operation from the handover mechanism so that the exchange of compression states information can be trig- 
gered when the CD is changed. 

A third way is to make use of soft-handover feature available in CDMA networks. The exchange of context can 



be performed during soft-handover period. This approach requires the co-operation from the radio network so 
that the two CDs can be informed when a soft-handover happens. 

To allow the decompression process at the new CD, the exchange of compression-state information should 
include the timestamp value and sequence number value in the last decompressed RTP packet by the previous 
5 CD. The two computer clocks at the previous and new CD need not be synchronized. When the new CD start 

to serve the RTP session handed over, it read its own clock and uses the reading as the clock reading for the 
last packet. 

• Secondly, as in UMTS and GPRS situation, the user IP will not be used until the point to leave CN for backbone 
10 network(a tunnelling protocol is used to transport user packet between BSS and CN). Therefore we can make use 
of this feature and put CP at the edge of CN, for example at GGSN so that the CP is transparent to the handover. 
In particular, by moving the CP into CN, the CP and the IP/PSTN gateway, which is required to make use the VoP 
service network, can be integrated. The drawback of this approach is the possible performance bottleneck at the 
CP in network. _ _ 

15 

[0073] Several modifications of the present invention will become readily apparent to those skilled in the art in the 
light of the foregoing disclosure. Therefore, the scope of the present invention should be interpreted from the following 
claims, such claims being read in the light of the disclosures. 

20 Claims 

1 . A mobile station for a packet switching radio network which includes a Voice over Internet Protocol application layer 
and Internet Protocol Stacks including Real Time Protocol, Transport Control Protocol, User Datagram Protocol 
and Internet Protocol layers, further comprising a compressor/decompressor to compress voice data, and means 

25 to send voice data and call signalling data separately and in different data formats to the link layer and the air inter- 
face of the mobile station. 

2. A mobile station according to Claim 1 in which the compressor/decompressor is arranged between the link. layer 
and the IP layer, the compressor/decompressor receiving both the voice data and the call signalling data. 

30 

3. A mobile transceiver according to Claim 1 in which the compressor/decompressor is arranged between the link 
layer and the Voice over IP layer, the compressor/decompressor receiving the voice data. 

4. A packet switching radio network comprising a plurality of mobile stations according to any one of Claims 1 to 3 and 
35 at least one network element in which there is compressor/decompressor means arranged to receive compressed 

voice data. 

5. A network according to Claim 4 in which the compressor/decompressor is arranged towards the edge of the core 
network adjacent the backbone network. 

40 

. 6. A network according to Claim 4 or Claim 5 in which the voice and data packets are routed through the Internet 

7. A network according to Claim 5 or Claim 6 in which the voice and data packets are routed through a gateway to the 
public switched telephone network. 

45 

8. A method of operating a packet switching radio network to provide voice services comprising separating voice data 
from call signalling and other data, whereby each packet containing voice data can be provided with compressed 
or removed RTP/UDP/IP headers. 

so 9. A method according to Claim 8 in which the voice packets for VoIP applications are sent as a link layer payload 
directly without going through IP layers. 

10. A method according to Claim 8 or Claim 9 in which each voice packet header comprises a cyclically-reset 
timeclick_number representing the sampling time of the packet payload; the timeclickjiumber being increased by 
55 1 for each sample duration time; and in which the headers are decompressed by counting the reset cycles by 
means of a separate clock; together with the received timeclick_number to provide the sequence number and 
timestamp of a decompressed header. 
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1 1. A method according to Claim 8 or Claim 9 comprising in a mobile station removing combined RTP/UDP7IP headers 
and placing voice data in RLC/MAC payload; and decompressing received voice packets by using an internal clock 
to obtain a timestamp value, and increasing the sequence number by 1 for consecutive packets. 

5 12. A method according to Claim 8 or Claim 9 comprising, in a mobile station, removing combined RTPAJDP/IP head- 
ers and placing voice data in RLC/MAC payload; and decompressing received voice packets by determining packet 
inter-arrival times to detect loss of any packet, and if such loss is detected, adjusting the timestamp value and 
sequence numbers of RTP headers of subsequently received voice packets accordingly. 

io 13. A method according to any one of Claims 8 to 12 in which the compression state of a voice packet header is estab- 
lished by making use of call set-up information over an out-of-band communications protocol between a mobile sta- 
tion and a compression/decompression in the network. 

14. A method according to any one of Claims 8 to 1 3 further comprising providing an out-of-band communications pro- 
is tocol between a serving compressor/decompressor in the network and other compressor/decompressors in the 

network, and, on handover of the call, exchanging compression context information relating to a current call 
between the serving compressor/decompressor and a new serving compressor/decompressor. 

15. A method according to Claim 14 in which the exchanged compression context information includes the timestamp 
20 value of the last decompressed RTP packet. 

16. A method according to Claim 15 in which the network is a Code Division Multiplexing Access network having a soft- 
handover facility, and preparing and performing exchange compression context information during a soft-handover 
period. 

25 

17. A first method of compressing and decompressing headers for a packet switching network comprises providing in 
each compressed header a cyclicalfy-reset timeclick_number representing the sampling time of the packet pay- 
load; increasing the timeclick_number by 1 for each sample duration time, counting the reset cycles, and from the 
count of reset cycles and a received timeclick_number, providing a sequence number and timestamp for providing 

30 ; a decompressed header. * • 

18. A method according to Claim 17 further comprising including in each compressed header an M bit; and decom- 
pressing a header when no M bit is received by increasing the packet sequence number of the decompressed 
header by the difference of the timeclick_numbers between the packet for which no M bit is received and the last 

35 previously received packet having an M bit 

* 

19. A second method of compressing and decompressing headers for a packet switching network comprises removing 
combined RTP/UDP/IP headers and placing data in RLC/MAC payload; and decompressing received packets by 
use of an internal clock to obtain a timestamp value, and increasing the sequence number by 1 for consecutive 

40 packets. 

20. A second method according to Claim 19 in which the network is a frame relay network. 

21 . A second method according to Claim 1 9 in which the network is an Asynchronous Transmission Made network. 

45 

22. A method of establishing a compression state of a packet header in a packet switching network by making use of 
call set-up information over an out-of-band protocol. 



50 



55 



11 




■a-if 



(a) Compression accessed by IP 



VoIP Applications 
? 



signaling 



TCP 



voice 



RTT/UDP 



IP 



Signaling u-t 
in IP ' 



inRLC/MAC 
over air interface , 



CD@MS 



6V 



Voice+smaU hd 
inRLC/MAC 
over air interface 



(b) Compression accessed by apps 



VoIP Applications 



signaling 



TCP 



IP 



Signaling 
in IP 
inRLC/MAC 
over air interface 



voice 



cixaMS 



Vcfce+smaUhd 
inRLC/MAC 
over air interface 



(=•10. 



MS 



44- 



TcnninalCD 



Air in terface 
| n A Node* 

W f 37 RNC 




12 



EP 1 056 259 A1 



Voice ia RTP or 
from App diractly 



| compressor | 



miaa 



IP header 



UDP header 



RTP header 



Voice pay load 



| de-compressor | 



VoUo ta RTP or 
to App dlraotly 



[de-compressor I 



IP header 



UDP header 



RTP header 



Voiee payload 



E 



| compressor - ] 



tit a aa 
Tfliaa 



Voice ia RTP or 
from App directly 



compressor | 

[Voice in RLc"| 



IP header 



UDP header 



RTP header 



Voice payload 



| de-com pressor | 



Voice 



de-compressor I 

A 1 



IP header 
UDP header 



RTP header 



Voice paytoard 



\ compressor 

{Voice ia RLC | 



13 



led party control: 



VoIP call oontrol 



r 



CD@ network 




Six b essagea: 

STATE START- 
STATB STOP 
STATE INPUT 
STATE.ENQRY 
STATE.ENQRY.RPL 
STATE HANDOVER 



CD ©network 





3rd party control: 








VoIP 




Mobility 




* 






■*call control 




M anasement 















\0to 



I compressor@MS 




CD@petwork | *- 



[ STATE_ENQRY_RPL 



oew CD@network 
"L 



! 



s 1 



14 



EP 1 056 259 A1 



Offloa 



EUROPEAN SEARCH REPORT 



EP 99 3G 4834 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Clation of donanant Mth motoabon, 
of ral w it pmim 



Rstwant 

todaan 



CtASSriCADON OF IMC 
WUCftTlOH (tatCU) 



Y 
A 



EP 0 820 168 A (TEXAS INSTRUMENTS INC) 21 
January 1998 

* page 4, line 40 - page 6, line 28 * 

* page 8~ line 13— line 28 * 

* page 9, line 22 - line 33 * 

* page 11, line 38 - line 48 * 
line 35 - line 48 * 
line 5 - page 28. line 53 * 
line 28 - line 25 * 
line 28 - line 25; figures 



22 



H84L29/06 
H84L12/56 



* page 18, 

* page 27, 

* page 39, 

* page 39, 
2B-0,3C,7B,7C * 

* page 39. line 28 
2B-D.3C.7B.7C * 



line 25; figures 



EP 8 841 831 A (AT A T CORP) 13 Hay 1998 

* column 1, line 5 - column 4. line 38; 
figures 2B-D.3C.7B.7C * 

* column 5, line 58 - column 6, line 17; 
figures 2B-D.3C.7B.7C * 

* column 7. line 15 - line 35; figures 
2B-0.3C.7B.7C * 

* column 7, line 15 - line 35; figure 1 * 

* column 7, line 15 - line 35; figure 1 * 



1.8 



22 



column 7, line 15 



line 35; figure 1 * 
-/-- 



1-4,6,8 

13 

5.7 



■j i rl hi b— wO—w t4> tat ataMrw 



H84L 
H04H 
K040. 



THE HAGUE 



3 November 1999 



Vaskimo, K 



OATEOORV OF CITED OOCUMBfTB 





15 



European Patent 



EUROPEAN SEARCH REPORT 



EP 99 36 4034 



DOCUMENTS CONSIDERED TO BE RELEVANT 



atop* 



0.Y 



CUOon of doeunwnt wih Merfion, appropriri*, 



WO 98 37665 A (VAZIRI FARAMARZ ;W1MSATT 
JOHN D (US); FONE FRIEND SYSTEMS INC (US)) 
27 August 1998 

* page 1, line 6 - page 3, line 1; figure 
1 * 

* page 5, line 4 - page 6, line 21; figure 
1 * 

* page 8, line 4 - line 18; figure I * 

* page 18, line 22 - page 11, line 1; 
figure I * 

* page 17, line 8 - line 19; figure 1 * 

* page 18, line 4 - page 19, line 9; 
figure 1 * 

* page 28, line 7 - page 29, line 5; 
figure 1 * 

* page 39, line 12 - line 22; figure 1 * 

* page 43, line 19 - page 44, line 12; 
figure 1 * 

* page 43, line 19 - page 44, line 12; 
figure 2A * 

* page 43, line 19 - page 44, line 12; 
figure 2A * 

S.CASNER.V.JACOBSON: -Compressing 
IP/UDP/RTP Headers for Low-Speed Serial 
Links- 

NETWORK WORKING GROUP, 
February 1999, 
pages 1-22, XP082121319 

* the whole document line 12; figure 2A * 

* the whole document line 12; figure 2A * 

-/-- 



T> W f WIH t M W u tl Mp Urt IW IM MI U p * » t» ttt 



dASianCAHONOFTME 
tfPUCAHON (MCLJ) 



-4,6,8, 

3 



5,7.22 



1.4.6,8 

13 



1ECHMCALRELOT 

(WW) 



2,3,5,7 



PtMOlMtfl 






THE HAGUE 


3 Hoventer 1999 


Vaskino, K 


CATEGORY OF CtTED DOCUMENTS 




«, tout pubfcfcftd «i, or 


«# . - ' A ^^^^^ J^M^M 


I ; dMUFWi m8h1 few 


■TPMMJM 


O : nuii wtltm ^tekimn 
P • htaniacMto tamgrm* 







16 



EP 1 056 259 A1 




EUROPEAN SEARCH REPORT 



EP 99 30 4034 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



fSMio oof d o c tf w fi t with indteaiion, whcf <ppropriM»» 
ofnrievnei 



lactam 



CLASORCATIOM OF THE 



A 
A 



SRIDHAR T PAI: *IP Telephony: Need for 
Standards" 
VOICE & DATA, 
21 May 1999. 
pages 1-3 t XP982121328 

* the whole document line 12; figure 2A * 

* the whole document line 12; figure 2A * 

US 5 841 854 A (MELAMPY PATRICK J ET AL) 
24 November 1998 



1.4,6.8 
13 



2.3.5.7 
1.8.22 



* column 1, line 13 - 

* column 4, line 28 - 
figure 2A * 

* column 7, line 36 - 

* column 8, line 25 - 

* column 16. line 47 
figure 2A * 

* column 13. line 31 
figure 2A * 

* colum 15. line 16 
* 

* colum 16. line 36 

* colum 18. line 1 - 



line 16; figure 2A * 
column 6. line 8; 

line 42; figure 2A * 
line 36; figure 2A * 
» column 12, line 34; 

• column 14 v line 4; 

- line 13; figure 2A 

- line 43; figure 2A 
line 7; figure 2A * 



TECHMCM.FCLDS 



THE HAGUE 



OitdenfMndliiMMl 

3 November 1999 



Vaskimo. K 



CATEGORY OF CfTEO 




17 




EUROPEAN SEARCH REPORT 



EP 99 38 4634 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Ctation et dmanant wilh Median, MhM* appropriate, 
of relevant paaaagta 



toetam 



CLASSACA1KMI OPTIC 
APPLICATION (lDLCi.7) 



EP 0 917 328 A (LUCENT TECHNOLOGIES INC) 
19 Hay 1999 

* page 1. paragraph 8 - line 7; figure 2A 

* 

* page 6, paragraph 31 - line 7; figure 2A 

* page 7, paragraph 38,39 - line 7; figure 
2A * 

* page 11, paragraph 68,69 - line 7; 
figure 2A * 

* page 15, paragraph 94 - line 7; figure 
2A * 

* page 17, paragraph 115 - line 7; figure 
2A * 

* page 18, paragraph 117,126 - line 7; 
figure 2A * 

* page 22, paragraph 155,157 - line 7; 
figure 2A * 

* page 24, paragraph 161,162 - line 7; 
figure 2A * 

* page 26, paragraph 166 - line 7; figure 
2A * 

* page 38, paragraph 191 - line 7; figure 
2A * 

* page 35, paragraph 237 - line 7; figure 
2A * 

* page 35, paragraph 237 - line 7; figure 
2A * 



,8,22 



TEDMCALFEUa 

(MLO.7) 



THE HAGUE 



Otto of OBflnptMBM Q) Mat 

3 November 1999 



Vaskimo, K 



CATEGORY Of CfTSO DOCUMENTS 




Tt 



ftftoftfy, 



18 



EP 1 056 259 A1 



ANNEX TO THE EUROPEAN SEARCH REPORT 

ON EUROPEAN PATENT APPLICATION NO. EP 99 38 483* 



Thia annex Rata the pater* tmrr&y m e»i**»» r«Ubng to the pater* documents cited in tt» ■My. nm i Mi) Fuitymi — rrrrpft 
The mw n bf are a* contained m the European Patent Offioe EDPeWoo 
The &*opee» Patent Ofoiem no waylaid 

83-11-1999 



Patent otooument 




Publication 




Pttarttmnty 


PuDeoatoon 


octad vi eearoh rape 


m 






memberfe) 




EP 0820168 


A 


21-01-1998 


US 


6602722 A 


14-12-1999 








JP 


10154949 A 


09-06-1998 



CD Oflltaoi 


e 

A 


1 ^ AC 

13-85- 


1 AAA 

"1998 


CA 


Z217838 A 


07-05-1998 










JP 


10173696 A 


26-06-1998 


WO yoJ/OOD 


A 


27-88- 


•1998 


AU 


6666898 A 


09-09-1998 










EP 


0966815 A 


29-12-1999 


lie coi i aci 


A 


^a 1 1 

24-11- 


1 AAA 

■1998 


US 


5862208 A 


19-01-1999 










US 


5566236 A 


15-10-1996 


EP 0917328 


A 


19-05- 


■1999 


CA 


2249817 A 


14-04-1999 










CA 


2249830 A 


14-04-1999 










CA 


2249831 A 


14-04-1999 










CA 


2249836 A 


14-04-1999 










CA 


2249837 A 


14-04-1999 










CA 


2249838 A 


14-04-1999 










CA 


2249839 A 


14-04-1999 










CA 


2249862 A 


14-04-1999 










CA 


2249863 A 


14-04-1999 










EP 


0912026 A 


28-04-1999 










EP 


0910198 A 


21-84-1999 










EP 


0917320 A 


19-05-1999 










EP 


0917318 A 


19-05-1999 










EP 


0912027 A 


28-04-1999 










EP 


0912012 A 


28-04-1999 










EP 


0918417 A 


26-05-1999 










EP 


0912817 A 


28-04-1999 










JP 


11289353 A 


19-10-1999 










JP 


11252183 A 


17-09-1999 










JP 


11275154 A 


88-10-1999 










JP 


11275155 A 


08-10-1999 










JP 2080022758 A 


21-01-2000 










JP 


11275156 A 


08-10-1999 










JP 


11275157 A 


08-10-1999 










JP 


11284666 A 


15-10-1999 










JP 


11331276 A 


30-11-1999 



1 

I 

9 

£ to nm aetata a*oi4thaamx:mOf5M 



19 



THIS PAGE BUNK (us™ 



EP 1 055 259 A1 




7.4- ^-fc 



(a) Compr»*8f©n accessed by P 



VoflPAppUcalK 





WW 



TCP | iOPAJDP^ b> ^ 



tP 



CD@MB 



cvtr air intafreq r 



ioRLC/MAC 
tJVW oil iaftstfkvi 



<&J Comprosftlon accessed by appa 



VciPAj*>r*adc*i 





< 5 










r 




TCP 




IP 



ovBrairbnteffbea 



io RLCVMAC 

owairimufeM 



Y 1 ^ 




12 



EP 1 CSS 269 A1 



v«3«« ■■ JtTP *r 



com pressor | 



tf I -Lift i 



IP he* Act 
UDP li«ft4«r 



de-corn pressor I 
— * 1 



Vek* In ATP «r 



[ de-compressor 



It- aitJaf 



kTP h»t4*r 



V6lo» pay to ad 



compressor 



V«i« (a ATP si 



compressor 



IP *«»*«t 



UDPkoidtr 



RTP b#a4»r 



VoiB< plyl<n4 



|de-com presaor 



de-compressor 



IP fc cider 



UDP h»d«r 



ft TP belter 



| compressor^ J 



13 



EP 1 OSS 259 A1 



Ird party control: 



-VoIP call c octroi 



CD@MS | 



^ 9lx n eit*K*ft: 

flTATE^STAR TE- 
STATE, *TOF 
ATATB^INPUT 
*TAT6_£KQRY 
STATE ^BH QR Y „RP L 
V^TATfi AMOO yBR^ 






3rd party control: 








VoIP 

call control 




Mobility 
Managem qui 













| compfegsor@MS 
10* 




CD@pgtwork Y 



1 STAra_BNQRY_Rft.i 



oew CD@neftvoik » 



14 



